[レポート] AWS ControlTower環境のカスタマイズとスケーリング #COP401 #reinvent

[レポート] AWS ControlTower環境のカスタマイズとスケーリング #COP401 #reinvent

Clock Icon2021.12.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS re:Invent 2021で行われた、「Customizing and scaling your AWS Control Tower environment」のセッションレポートです。

セッション概要

DESCRIPTION

AWS Control Tower provides the easiest way to set up and govern a secure, multi-account AWS environment. Users can further customize their AWS Control Tower landing zones with the Customizations for AWS Control Tower (CfCT) solution. In this session, discover best practices for deploying a scalable CfCT pipeline that allows you to test your customizations in a lower environment before promoting them to a production landing zone. Learn about some of the most common CfCT customizations you should consider for your landing zone, including identity and network management and governance.

SPEAKERS

  • Nivas Durairaj
  • Remek Hetman

SESSION LEVEL

  • 400 - Expert

レポート

アジェンダ

  • AWS Control Tower landing zoneについて
  • 一般的なカスタマイズ
  • Control Towerカスタマイズソリューション(CfCT)について
  • CfCTのベストプラクティスと注意点
  • マルチOrganizationへの展開
  • End-to-end account vendingの例

AWS Control Tower landing zoneについて

  • Control Towerとは
    • マルチアカウント環境のセットアップを自動化
    • ベストプラクティスの設計とガードレールの展開
    • ベストプラクティスに基づいたAWSアカウントの発行
    • コンプライアンス状況を確認できるダッシュボード

  • Control Towerが提供するLandingZone
    • Organization、SSO、Service Catalog
    • CloudTrailの集約
    • セキュリティOU配下にログアーカイブ、Auditアカウント
    • Config Rule・Conformance Packsによるベースライン環境

一般的なカスタマイズ

  • どのようなカスタマイズを展開するかを検討する
  • セキュリティ、ネットワーク、SharedService、ワークロードアカウントそれぞれ
  • カスタマイズカテゴリTOP5
    • Identity
      • IDプロバイダーとAWSフェデレーション
      • OktaやAWS、ADFS等々
      • どのようなIAMロールをAWSに作成するか
      • DevOpsロール、ReadOnlyロール、ネットワーク管理者など
    • Security and compliance
      • GuardDuty、Security Hub、IAM AccessAnalyzerなどをセットアップする
      • 暗号化でどのようなポリシーのキーを利用するか
    • Networking
      • オンプレミスとどのように接続するか
      • Transit Gatewayを利用し全てのVPCとピアリングすることもある
      • 新しいVPCを作成する時はどのように提供するか、CIDR、IPアドレスなど
      • セキュリティグループをどのように設定するかも考慮が必要
    • Logging
      • Landing ZoneはCloudTrailを作成
      • データイベントは記録されないため、追加の作成を検討する必要がある
      • VPCフローログ、Firewallログ、CloudWatch Logsなどの集約
    • Control
      • Configルールで管理
      • S3やSNS、KMSを作成する場合はリソースポリシーを考える必要がある
      • ConfigルールからLambdaを自動で設定して組織外へのアクセスを防ぐ
      • Service Catalogを使ってテンプレートを作成する

Control Towerカスタマイズソリューション(CfCT)について

  • これらのカスタマイズをどのように展開するか
    • Control Towerカスタマイズソリューション(CfCT)を利用する
    • 自動で全てのアカウントにスタックをデプロイ可能
    • SCPの展開にも利用することができる
    • マニフェストファイルの作成が必要
    • S3またはCodeCommitにデプロイ
  • CfCTの仕組み
    • ソースにアップロードするとCodePipelineがトリガーされる
      • CodeBuildが実行され、テンプレートとポリシーにエラーがあるか検証
      • 内部的にはcfn-nagを利用している
      • 次にStepFunctionでSCPの展開を呼び出す
      • その次はCloudFormationテンプレートをデプロイ
    • もう1つのトリガーはControl Towerが新しいアカウントを作成したとき
      • ライフサイクルイベントをEventBridgeで収集
      • SQSにアップロードしてLambdaをトリガー
      • あとはソースへのアップロードと同じフロー
  • マニフェストファイルの例

    • Idpのデプロイ
    • グローバルサービスロールの展開
    • SNSトピックの一元化
    • デフォルトVPC削除やIPアドレスの払い出し
    • VPCエンドポイントの作成 …etc

CfCTのベストプラクティスと考慮事項

  • 複数のパイプラインを管理しないためにCloudFormationサポートされているものはCloudFormationで管理すべき
  • 並列展開と順次展開オプション
    • マニフェストファイルの最初から1つずつ順番に展開される
    • そのため2番目以降は依存関係を持つことができる
    • 複数リージョンで展開する場合は並列で展開すると時間短縮になる
  • フォールトトレランスのパーセンテージ
    • デフォルトは10%
    • 40インスタンスをデプロイするとき、4つ失敗しても継続する
    • 一貫性を保つ必要があれば、1つ失敗したら展開を停止するように0を設定する
  • Service Quotes
    • 多くのリソースを追加するため、上限に遭遇する可能性がある
    • どのように制限を調整するか
      • アカウント作成時に管理アカウントのServiceQuotesで組織テンプレートを作成する
      • 一部の制限は時間のかかるケースがあるためテストすること
  • グローバルリソース
    • IAMロールやS3バケット
    • IAMロールを作成する際、違うリージョンでも同じ名前のロールを作成することがある
    • これらを管理する方法は2つがある
      • もう1つはロール名にリージョンを自動で追加する
      • 別のテンプレートでリソース作成前にロールを作成する

マルチOrganizationへの展開

  • セキュリティリファレンスアーキテクチャ(SRA)
  • Account Factory for Terraform(AFT)

    • Control Towerでアカウントの登録が可能
    • GuardDutyやCloudTrailデータイベントもサポート
    • デフォルトVPCの削除もできる
    • これから多くの機能を追加予定
  • マルチOrganizationの管理
    • 開発用と本番用OUを作成持つ
      • テストの観点から推奨
      • 開発用と本番用のテンプレートを分ける
      • もっと簡単なのはパラメータで分けること
      • ブランチを分けて変更をトリガーする

End-to-end account vending solutions example

  • ユーザーがチケットシステムを使用して新しいアカウントをリクエスト
  • Lambdaを使ってService Catalogからアカウントを発行
  • リクエストの詳細はDyanamoDBに保存
  • アカウント発行後はCfCTが自動で初期セットアップ
    • ADにアカウントを登録、ユーザーにアクセス許可を付与
    • CloudWatch Logsの宛先に新しいアカウントのアクセス許可を追加など
  • セットアップ完了後、チケットシステム側のLambdaを呼び出しステータスを更新
  • アカウント発行が完了したことをユーザーに追知

まとめ

CfCTの紹介だけでなく、マルチアカウント環境で行われる一般的なカスタマイズや、セキュアな環境を維持するためのSRAの紹介など盛り沢山のセッションでした。

Control Towerを利用するにあたり、どのようにアカウントをセットアップしていくか、どのようなカスタマイズを行なって運用を楽にするかは必ず直面する課題です。CfCTやAFTを正しく理解して、うまく活用していきたいですね。

個人的にSRAとマニフェストファイル例があるGitHub紹介があったことが一番の収穫でした。この辺りについても詳細をどこかで紹介できればと思ってます。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.